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MAST FINAL REPORT 


1.0 Introduction 

To take advantage of past research that has been performed in distrib- 
uted architecture systems and the current research work in progress, it was neces- 
sary to seek out information from other facilities that have also been studying dis- 
tributed architectures. It was beneficial to see what systems these facilities had in- 
stalled and found useful, as well as, to discuss their conceptual ideas for the future. 
Visits were made to five facilities: U.S. Army Corps of Engineers Waterways Ex- 
periment Station, Vicksburg, Northrup Corporation Hawthorn, General Dynamics 
San Diego, General Dynamics Ft. Worth and NASA JSC. An attempt to visit the 
Bell helicopter facility in Dallas was not allowed by the Bell marketing depart- 
ment. Attempts to visit the Boeing facility in Seattle, NASA Langley and other 
facilities were unsuccessful due to timing, budget or other causes. 

2.0 Waterways Experiment Station Vicksburg 

On January 18, 1989 J. K. Owens, F. M. Ingels, and S. P. Daniel visited 
with Mike Ellis of the U.S. Army Corps of Engineers Waterways Experiment Sta- 
tion (WES). 

Mike Ellis 

Department of the Army 

Waterways Experiment Station, Corps of Engineers 

P.O. Box 631 

Vicksburg, Mississippi 39180-0631 

(601)-638-0670 

At this facility, a Facility- Wide Fiber-Optic Communications Network is 
being installed. The goal of this facility is the connection of a widely distributed 
campus of 108 buildings spread over 600 acres by an all digital communications 
network. There are also plans to add a super computer to the facility and the net- 


work would serve as the primary means of access to most users. A diagram of the 
WES backbone network is shown in Figure 1. 

The design goals for the network were connectivity and the ability to up- 
grade easily as new hardware became available. The Information Technology lab 
at WES performs compatibility (connectivity) test but few performance experi- 
ments for delay and throughput. 

This facility is a good model for the Marshall campus area network that 
will be part of MAST or that will connect to MAST. 

3.0 Northrup Corporation Hawthorn Facility 

During the month of February J. K. Owens, F. M. Ingels, and S. P. 

Daniel visited the Northrup facility in Hawthorn, California. The engineers at the 
facility are involved in the design and test of avionics and therefore are knowl- 
edgeable in the area of avionics testbeds. 

At the Northrup plant Peter Shaw, Tom Winfrey, Nareh Shah, Jim Evans 
and Leo Stein were visited. Mr. Shaw can be reached at (213) 332-6110. 
Northrup’s address is 

One Northrup Ave 
Hawthorne, CA 90250-3277. 

At the Northrup facility, we were especially interested in the Vehicle 
Management System (VMS) lab. In this lab a ProNET-80 is used to connect sev- 
eral Force 68020 computers. At present they have 12 computer systems connected 
but they plan to connect 48 Force Motorola 68020 computer systems together over 
a ProNET network in the near future. This system is used to simulate the flight 
control subsystem of an aircraft. Their eventual goal is to have many of the air- 
craft subsystems modeled in the various computers and combine these to deter- 
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Figure 1 WES Backbone Network 
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mine performance and compatibility. The system is designed to allow a pilot in 
the loop. 

The installation of the ProNET has resulted in the staff developing ex- 
pertise with ProNET drivers for several computers. ProNET drivers for VAX sys- 
tems are available from Proteon but support for other systems is lacking. One of 
the problems that was encountered was the need for software delays in the driver. 
If two consecutive packets are sent to the same address they can over-run the re- 
ceive buffer resulting in lost packets. This occurs without any error indications. 
The problem was alleviated by looking at the Sun ProNET driver that had soft- 
ware delays built-in. These delays were added to the Northrup drivers and cured 
the error. One point of interest at the lab is that software is written directly in 
Ada. 

Another problem with ProNET-80 is that the system is protocol depen- 
dent. The internal protocols between two lower level networks using a ProNET 
backbone must be the same. A method of packet encapsulation should be added 
to the protocol so that an Ethernet packet bound for a station on a token passing 
bus can easily be transported over the ProNET backbone. [TREL88] 

The wire center nodes of the ProNET system are used extensively at this 
facility. If at all possible new connections are added at an existing wire center in- 
stead of adding a new node to the ring. 

A more detailed look at the VMS concept is appropriate. The Northrup 
philosophy is to combine all flight-critical control sub-systems into a single fault- 
tolerant system. The typical sub-systems for a launch vehicle are shown in Fig- 
ure 2.[CHEN88] The use of VMS is part of the Integrated Control Law Evalua- 
tion program (ICLE) and the flow of evaluation and refinement is shown in Figure 
3. The expected benefit of this approach is the functional and physical integration 
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Figure 2 Subsystems for Launch Vechicle VMS study 

of the sub-systems. Functional integration implies that control functions are im- 
plemented with respect to the whole system as opposed to sub-systems. This al- 
lows the inherent couplings between sub-systems to be dealt with directly. Physi- 
cal integration implies that either resources are shared or that sub-systems are 
physically combined. 


The key to realizing the benefits of this approach is to design a system 
architecture that not only meets the functional requirements, but also achieves a 
good balance between minimizing the technology risks and optimizing various per- 
formance metrics such as weight, cost, supportability, etc. As system characteris- 
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• VMS Design 
Guidelines 

Figure 3 VMS Analysis in ICLE Program 

tics vary widely, no single VMS architecture is expected to be optimal for all sys- 
tems. 


The VMS architecture allows a trade-off analysis between central and 
distributed processing to be performed. This is especially important to NASA as 
smart sensors and other intelligent subsystems are augmenting the central flight 
controller. Another area for study is data communications within the vehicle. 

Data rates in excess of the capabilities of MIL-STD-1553B are being required and 
a VMS type testbeb would be useful in studying the application of advanced proto- 
cols. Two other areas that may be studied with this facility are control task parti- 

i 

tioning and function synchronization. The study of control tasks partitioning is to 
determine the optimal way to divide task that run on several processors. Function 
synchronization is the study of the effects of asynchronus operation and how to 
minimize its undesirable effects. There are several other system design consider- 
ations that may be studied in the lab. These include: fault detection and isolation, 
reconfiguration, redundancy, maintainability, and supportability. 
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Two configurations of the VMS lab are presented in Figures 4 and 5. 
The major differences between the configurations is task partitioning and commu- 
nications. Configuration one uses a central processor that can preform all control 
tasks or may allow a subsystem processor to control the subsystem. Configuration 
two does not contain a central processor, this requires that any operation involving 
two or more systems must be distributed among the subsystem controllers. Anoth- 
er configuration is a hierarchical approach that allows data bus requirements to be 
reduced. The resulting trade-off in delays between subsystems and overall per- 
formance may be studied. A configuration to study the performance trade-offs of 
smart sensors would include additional processing and control at the sensors and 
effectors. 

A problem with the VMS lab is that there are few diagnostics available 
in either software or hardware to pinpoint errors or system faults. This is a prob- 
lem with any new system of a complex nature. Using hardware with self-test fea- 
tures greatly reduces debug and maintenance time. The basic VMS lab including 
system under test, simulation and instrumentation units and a software develop- 
ment facility is presented in Figure 6. 

4.0 General Dynamics San Diego Facility 

At the GD plant Ed Jones, Delbert Ingalls, Eric Hogan, John Sessions, 

Kelly Wallace and Andy Schicking we visited. Mr. Jones can be reached at 
(619) 547-4581. The GD Address is 

General Dynamics 

Space Systems Division 

MZ 24-8710 

PO Box 85990 

San Diego, CA 92138-85990 

The GD facility includes four avionics testbeds. They have Atlas, Cen- 
taur, Titan and general purpose testbeds. The main emphasis for these labs is 
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Figure 4 Implementation of VMS Configuration 1 
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Figure 5 Implementation of VMS Configuration 2 
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Figure 6 VMS Laboratory 

ground support of the launch vehicle up to launch. In the future they hope to ex- 
tend the capabilities of these labs to allow application to all phases of flight. The 
labs lack a common local area network tying the computers, control center, and 
hardware together. This addition is planned for near term improvement. 

The labs basic configuration is an avionics hot bench with connections 
to several supporting computers. Emphasis is placed on real harnesses and hard- 
ware. The lab’s support equipment includes raised floors, large doors, heavy duty 
hoist and a workshop area for maintenance and construction. Also, a central data 
display center with large screen displays is combined with the labs for data analysis 
and presentation. 
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Discussions with Ed Jones on the future of the GD labs and their work 
on the Heavy Lift Cargo Vehicle (HLCV) study were beneficial to this study. The 
future direction of the GD testbeds is to add local area network technology and 
computing resources to enhance their present facilities. These additions will make 
the labs more versatile. Their fourth quarterly report for the HLCV study was 
used as a source for Figures 7 thru 13.[GD89] Figure 7 presents the basic configu- 
ration of the proposed lab. It is important to note the use of local area networks 
to tie together distributed processing systems. The use of microprocessor based 
test equipment allows ease of control and modification of the facility. The com- 
munication interfaces for the testbed are shown in Figure 8. The testbed should 
have direct connections to both the main and the control processors. Figure 9 de- 
picts the main simulation processor. In order to allow for expansion this unit 
should be a system of microprocessors or several small computer systems such as 
workstations. Figure 10 shows an experiment control processor. This processor 
would be used to control testbed hardware and apply stimuli to the system under 
test. Figure 11 is of the guidance and navigation testing facility. This facility in- 
cludes a three axis table and several 80386 microprocessor for stimulus generation 
and system control. A system to model engine controllers is presented in Figure 
12. One of the more difficult tasks for this system is to provide emulation of valve 
action in software. Figure 13 presents an approximate vehicle computer process- 
ing timeline that may be used in the determination of required computing re- 
sources for the lab. 


5.0 General Dynamics Fort Worth Facility 

A visit to the Fort Worth General Dynamics facility was made in April. 
The principle personnel from GD Fort Worth were Don Brown (817-763-2628) 
and Phil Barry. 
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Figure 7 Basic Lab Configuration and Communications 
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Fieure 8 Avionics Testbed Interfaces 
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Figure 10 Experiment Control Processor 

The GD Address is 


General Dynamics 
MZ 1771 
PO Box 748 
Ft. Worth, TX 76101 

The avionics test facility there is mainly interested in the test of man- 
ufactured products to insure that they meet specs and to check that interfaces be- 
tween sub-system operate properly. 
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Figure 11 Guidance and Navigation Testing Facility 

The computer system used by GD on most projects is the Harris H se- 
ries. The computer communicates with the system under test through shared 
memory. If the system under test has a MH^STD-1553B bus then a MBI unit is 
added as shown in Figure 14. The MBI unit is responsible for moving information 
from the shared memory to the communications bus and placing data from the bus 
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Figure 12 Propulsion Subsystem Testbed for MAST 
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into the memory. GD also occasionally adds an additional connection to sub-sys- 


tem buses and microprocessor buses to allow the main computer direct access to 
this level of the system under test. 
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Figure 14 Standard Test Configuration (MIL- 
STD-1553 Bus under Test) 

The philosophy at GD is that any facility that is used by a project typi- 


cally becomes owned by that project for the duration of the project. Mr Brown 
was interested in the concept of developing a system that could be used from the 
design phase through the development of tests for the end product. However, he 
stated that when this has been attempted in the past a project came along that 
dominated and then took exclusive access of the facility. The plant at Fort Worth 
was very similar to the plant at San Diego in that the main concern seems to be 
the testing of sub-systems as opposed to design and test of new and developmental 
products. It was stated that past experience has shown that a meaningful test facil- 
ity usually cannot be built until the prototype has been manufactured. Both GD 
facilities indicated that test stands for small sub-systems could be built at an early 
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stage but that technology and project requirements change too rapidly for a sys- 
tems development lab to keep pace. 


6.0 NASA JSC Facility 

In March 1989 Russ Nelson of Ford Aerospace and Glenn LeBlanc of 
the Johnson Space Center (JSC) were visited. They are involved with the Space 
Station DMS development testbed at JSC. 

Russ Nelson 

713-335-6157 at Ford Aerospace 

713-483-7579 at JSC 

Glenn LeBlanc 

713-483-7015 at JSC 

Their address at JSC is 

National Aeronautics and Space Administration 

Lyndon B. Jhonson Space Center 

MZ FS53 

Houston, TX 77058 

They are studying the application of FDDI to the space station. They 
are presently studying the performance of the Fiberonics implementation of the 
FDDI protocol. Performance issues such as backbone delay, throughput, efficien- 
cy, and effects related to packet size are being studied. The FDDI network shown 
in Figure 15 is composed of four nodes. Three of the nodes have HP 4972 A La- 
nalyzers and a Sun workstation. These nodes generate traffic and measure per- 
formance. The fourth node is a gateway to other systems. The system will support 
Apollo and Sun workstations and IBM PS/2 computers. One of the features of the 
testbed is the use of Isolan Fan-out units from BICC Data Networks. These units 
are used as wire centers and support up to 8 or 16 connections to a single FDDI 
node depending on the model used. 
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Figure 15 Space Station Control Center 
End-to-End Test Configuration 
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The performance studies do not include radiation resistance, triple re- 
dundancy or single nodes generating more than 10 megabits/second. These items 
should be covered for this application. It is thought that any node that generates 
more than 10 megabits/second will be given a dedicated link. 

The testbed has been used to determine failure recovery times for the 
system. Two values of interest are the 25 millisecond power loss recovery time and 
the 96 microsecond cable rehook recovery time. Documentation on the Fiberon- 
ics system is not complete at this time and this has led to difficulties. The station 
management software produces many diagnostics but their meaning is not docu- 
mented. 


Preliminary test of the system is scheduled to be concluded in late June. 
An internal report will be published and should be available in July. The system 
will eventually be used to model communications from JSC to the space station 
and back as shown in Figure 16. It is planned that the hardware at JSC and on 
board the station will be the actual hardware and only the radio link will be mod- 
eled. 


7.0 The Proposed Local Area Network for the NASA/MSFC 
Testbed Backbone 

Though ProNET is available and in use now, the future standard for 
high speed local area networks appears to be the Fiber Distributed Data Interface 
(FDDI). Therefore, FDDI is the recommended backbone LAN for the MAST fa- 
cility. A typical avionics architecture using FDDI and MIL^STD-1553B is shown 
in Figure 17. The MIL-STD-1553B bus is used as a local distribution network for 
subsystems while FDDI is used as a backbone LAN for communications between 
subsystems. The relevant standards for FDDI are presented in Figure 18. Notice 
that Northrup is heavily supporting FDDI even though they presently use ProNET 
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Figure 16 JSC ETC Interfaces 


for their high speed LAN requirements. This would lead one to suspect that they 
will upgrade to FDDI as hardware becomes available. A functional block dia- 
grams for FDDI is shown in Figures 19 and 20 and a communications model is 
shown in Figure 21. The important information in these figures is that FDDI is 
being developed with military requirements in mind. This should make compo- 
nents available that meet NASA’s space qualification requirements. FDDI’s use of 
counter rotating rings as shown in Figure 22 and optical bypass shown in Figure 23 
should allow FDDI to meet NASA’s requirements for redundancy and fault toler- 
ance. For many FDDI systems up to three consecutive nodes may fail and go to . 
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Figure 17 Proposed Distributed Avionics Architecture 


24 
















FDDN 



^Northrop ASD 
Participation 


Figure 18 Standarization Efforts Relevant to FDDN 

optical bypass before the ring is broken for the remaining stations. For these rea- 
sons it is proposed that FDDI be used as the MAST backbone. 


7.1 The Proposed Architecture for the Testbed 

The visits to various facilities were useful in developing and refining the 
proposed architecture for MAST. The Northrup facility and General Dynamics 
proposed expansions were major influences. The Northrup VMS philosophy is 
generally what is generally followed with the upgrade to a FDDI backbone 
LAN.[COHN88] The proposed system is shown in Figures 24 and 25. Figure 24 
assumes that each stage has its own LAN and multiple stage vehicles have bridge 
nodes between stages. This introduces a point of failure and the problem of pack- 
ets on the system addressed to dropped stages must be dealt with. This system 
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Figure 19 FDDN Functional Block Diagram 

would be considered inferior to the system presented in Figure 25 because the 
Backbone network does not have access to each stage. These access points would 
be used to record bus traffic and to input stimuli to the system. They would also 
be used to input initial conditions and supply responses from nodes that are tem- 
porarily out of the system. 
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Figure 20 FDDI Functional Block Diagram 
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Figure 21 FDDI Communications Model 
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Figure 22 FDDN LAN Node Attachments 
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Figure 24 Possible MAST Topology 
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Several points that should be made about the testbed are: 

• The use of microprocessor based test equipment and communica- 
tions is essential to the requirement of easy flexibility. 

• The Local Area Network used must have bandwidth available for 
future expansions of the facility. The use of a fiber system will allow 
this even if the protocol is changed. However, FDDI is expected to 
be used well above 100 megabits/second as hardware becomes avail- 
able. 

• The computing systems for simulation and control should be com- 
posed of distributed microprocessing systems so that as requirements 
grow the system can expand easily. 

• The technology used in the facility should be as up to date as pos- 
sible to avoid obsolescence but standards should be used wherever 
possible. 

Several points that should be made about the testbed facility are: 

• Use raised floors throughout the facility. This allows for easy 
cable installation and modification 

• Provide ramp access to all doors or to at least one large door. 

• Plan for obsolescence and expansion. Over design power and air 
conditioner systems by at least fifty percent. 

• Provide convenient access between labs. Equipment will often be 
moved between labs. 

• A workbench area should be provided for all areas. Maintenance, 
construction and installation task will be required often for this facil- 



• Assessable storage for manuals and computer media should be 
provided. 

• Make cable lengths longer than required and up to the farthest 
corner when practical. Expansion will require the movement of 
equipment. Also route cable through trays and label cables every 
three feet when practical. 

• Use incandescent lighting where possible to reduce noise. Pro- 
vide separate dimmer controls for areas with video displays to reduce 
glare. 

Display Area: 

• Provide a presentation and display area that will accommodate 
approximately thirty people. 

• Provide several large screen displays for presentation. 

• Provide for the display of information from any workstation in the 
facility. 

• Provide slide and viewgraph facilities for presentations. 

• Provide workstation area with stations to control presentation. 
Main Computer Room 

• Provide separate computer room for noise control. 

• Room should be central to facility to reduce communications 
route lengths and delays. 

• Provide visibility to and from other areas. 
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Workstation Environment 


• Use a minimum of a six foot table for each station. The footprint 
of most stations monitor and keyboard covers smaller tables and, 
therefore, does not leave room for documentation and scratchwork. 

• Provide accessible storage for documentation and backup media. 

• Provide small demonstration area for approximately ten people. 
Systems Integration Area 

• Provide separate area for the integration of facilities in other sec- 
tions. 

• Provide convenient access to other labs and main computer room. 
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